iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 2
1
AI & Data

資料工程師修煉之路系列 第 2

[Day 2] Reliable, Scalable, and Maintainable Application (1)

  • 分享至 

  • xImage
  •  

其實今天的很多系統都是 數據密集型 應用系統,也就是 數據量大、複雜、且速度快

有別 10 幾年前的 計算密集型,CPU 時脈才是系統的瓶頸。

現在的數據密集型應用系統都包含了以下功能:

  • 儲存資料 (database)
  • 加速讀取昂貴操作的結果 (cache)
  • 讓 user 用 keyword 或其他方式檢索資料 (search index)
  • 寄送訊息到另一個 process,用非同步的方式做某些事 (streaming processing)
  • 定期的處理大量已累積的資料 (batch processing)

數據工程師的工作就是選擇合適的工具把上面這些搭建起來。

數據系統

至於什麼是合適的工具呢?現今我們常用的工具並沒有一個非常明確的 分類

例如你可以用 Elasticsearch 做你的 database,也可以用 Redis 做你的 message queue,

雖然我們直覺都不會這樣幹啦!但只要用的合理,符合等會講的 Reliable, Scalable, Maintainable 原則,又何嘗不可。

下圖為組合多種組件的數據系統架構圖:

figure_1-1

個人認為這些是現在數據系統的基本架構,這裡可以有很多討論的細節,每一個區塊都能獨立成一個系統架構,但基本概念是一致的,有應用程式就有 DB,想要 Request 回覆更快就用 cache,數據工程師現在更需要有能力成為一個數據系統的架構師。

當你在建立數據系統時,我們必須確保 3 個主要原則:

Reliable (可靠的)

​ 系統應該只完成我們預期它會完成的事,就算發生錯誤也是如此。

Scalable (可擴充的)

​ 系統能支持未來成長的流量。

Maintainable (可維護的)

​ 系統能同時讓開發工程師或維運工程師正常使用,不會因為某些原因造成某方的生產力下降。

接下來的篇幅會針對這 3 個主要原則詳細說明。

Reliable (可靠的)

對系統來說,工作正確 是預期能完成下述幾項:

  • 正確執行 user 預期的函式
  • 能容忍 user 的小錯誤和軟體層級上能預想到的錯誤
  • 對需求端的 use case 能有效率的執行,並產生可預期的資料
  • user 有經過授權才能做事

莫非定律(Murphy's Law):「凡是可能出錯的事就一定會出錯」

能應對錯誤的系統稱為 falut-toerant (容錯),這裡要跟 failure 做區隔,我稱它為 系統掛點

這種掛點是會讓你半夜需要爬起來處理的嚴重系統問題,

沒有能完美應對所有錯誤情況的系統, 所以合理的是想像出各種可能會發生的錯誤而提前應對,進而避免累積的錯誤導致系統掛點。

在 ETtoday 我們在測試系統時,也常用手動 kill process 的方式來觀察系統是否可靠,觀察 Servicce 是否會重啟或者Leader 有無被正常的選出來等等。

硬體錯誤

當你都在用雲端時,這件事對你是無感的,什麼硬碟壞軌、記憶體故障等等都不甘你的事。

但公司是私有雲時,這件事對軟體的可靠程度就很重要了,在建置系統時,最有效避免此錯誤的方式就是 redundant (冗餘) ,像硬碟的 RAID 設定就是如此,root 硬碟掛掉時,機器還是能正常運作,最棒的是準備 redundant 的機器,確保系統在修復期間是 zero downtime,服務不中斷。

軟體錯誤

上一點提到的硬體錯誤是屬於弱關連,一顆硬碟故障了不會造成另一顆硬碟也故障,

但軟體層面的錯誤關連性就比硬體錯誤強了,舉例來說:

  • 某些不好的 input 會導致多個軟體掛掉,像 Leap second issues - June 30, 2012 會導致 Linux Kernal 發生 3 個可能的 issue。
  • 某些執行中的 process 可能共用了系統資源,如 CPU, memory, 頻寬等等。
  • A 軟體變慢導致同台機器的 B 軟體也變慢或回覆非預期的結果。
  • 瀑布流系統掛點,一個小的錯誤可能會造成另一個軟體的錯誤,最終演變成災難。

避免方式就是把測試寫好、獨立執行資源、進程隔離、軟體掛掉自行重啟等等,另外也要做好機器與軟體的監控。

人為錯誤

事在人為,錯誤亦同。

好的系統應該要組合下述幾項:

  • 盡可能的降低錯誤的機率。
  • 有與生產環境相同的沙箱環境做測試、實驗。
  • 能通過完整的測試,包含單元測試、整合測試、人工測試。
  • 系統能簡單且快速從人為錯誤中恢復;例如能透過 DevOps 快速 rollback 前一版本、逐步釋出 (rollout) 新版本程式、有工具能重新計算舊的資料。
  • 設置詳細且簡單的監控機制,諸如 performance 指標、錯誤率指標等等,監控機制能讓工程師們能及早因應系統錯誤做出反應。

系統沒有符合 Reliable 後面的東西都甭談了,有時候我們會因為成本或時間考量而犧牲一定的可靠性,

工程師需要培養 你在危機時刻依然會遵循的紀律原則,在這個情況下,恪遵紀律原則是避免陷入危機的最好途徑。

Scalble (可擴充的), Maintainable (可維護的) 就明天在談啦!


上一篇
[Day 1] 沒時間可以不用看的前言
下一篇
[Day 3] Reliable, Scalable, and Maintainable Application (2)
系列文
資料工程師修煉之路30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言